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ABSTRACT 


Improvised Explosive Devices continue to harass, maim, and kill innocent men, women, 
and children, as well as numerous coalition and U.S. forces. To combat this terror, the 
U.S. government has employed significant resources across a diverse range of dedicated 
researchers and testers. The urgency of their task cannot be overemphasized. However, 
in working so diligently to test the separate components of a defeat system, it is 
hypothesized that opportunities are being missed which could effectively utilize all of the 
information available across the test enterprise. The purpose of this thesis is to identify 
the organizations and activities involved, the information shared, and the processes 
employed by organizations within the JIEDDO Test Board (JTB). The objective is to 
provide an accurate representation of the process, and where the main decision points and 
bottlenecks occur. The conclusions achieved by this research are provided to enhance the 
JIEDDO test process system. The goal of this study of the JIEDDO process is to 
contribute to improving information sharing and knowledge management among 
stakeholders involved in the JIEDDO Test Board Enterprise. 
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I. 


INTRODUCTION 


A. BACKGROUND 

This research was conducted to provide a Joint organization within the 
Department of Defense, a snapshot of its process from the perspective of the end users. It 
is intended to be a representation of the support and products provided, and how the 
support and products are utilized by the end users. 

1. The Threat 

Improvised Explosive Devices (lEDs) continue to harass, maim, and kill innocent 
men, women, and children, as well as U.S. and Coalition forces in Iraq and Afghanistan. 
Currently over 60% of U.S. casualties are caused by lEDs {Military Casualty 
Information, 2011). The urgency of this task cannot be overemphasized. lEDs have 
been, and continue to be a steady threat to U.S. personnel, while the War on Terror 
continues. U.S. casualties related to lEDs have consistently increased since the 
beginning of the War on Terror, from 12 in 2001 to 499 in 2010 {Military Casualty 
Information, 2011). As of 2010, 1446 U.S. service members and 2281 total U.S. and 
Coalition service members have been killed as a result of lEDs {Military Casualty 
Information, 2011). 

2. The Response 

The U.S. Government has employed significant resources across a diverse range 
of dedicated researchers, developers, and testers to create tools to combat the terror of 
lEDs and counter the lED threat. One response to the lED threat by the U.S. Government 
was to create an organization tasked with countering the lED threat. The Secretary of 
Defense signed DoD Directive 2000.19E, which directed the development of the Joint 
Improvised Explosive Device Defeat Organization (JIEDDO), a joint organization 
designed to combat the lED threat (U.S. Department of Defense, 2006). The Directive 
which created JIEDDO, states that JIEDDO shall focus (lead, advocate, and coordinate) 
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all Department of Defense actions in support of the Combatant Commanders’ and their 
respective Joint Task Forces’ efforts to defeat Improvised Explosive Devices as weapons 
of strategic influence. Under this directive, JIEDDO has developed its creed: “Attack the 
Network; Defeat the Device; Train the Eorce (from U.S. Department of Defense, 2011).” 

3. The Organization 

DoD Directive 2000.19E gives JIEDDO the authority to form functional boards 
that perform specific roles to assist JIEDDO in accomplishing its mission. In total the 
Directive assigns duties and responsibilities to seven separate boards, groups and teams. 
One such board is the Joint Improvised Explosive Device Defeat Organization Test 
Board (JTB) and will be the focus of this research. This DoD Directive gives the JTB the 
authority to synchronize all testing and evaluation events which fall under JIEDDO 
influence and to coordinate with military departments to quell the possibility of redundant 
testing, under five specific areas of authority, consisting of: 

• Track and identify all JIEDDO test events. 

• The use of testing sites and laboratories in order to collaborate, thus 
decreasing redundancy of testing 

• Scheduling authority for testing events 

• Coordination and reporting of new technology assessments to the 
Combatant Commanders 

• Provide recommendations to the JIEDDO Integrated Program Team (U.S. 
Department of Defense, 2006, p. 16, 17) 

Adhering to these five areas of authority, the JTB conducts its operations as a multiple 
organization enterprise. 

4. The Enterprise 

The JTB is global in nature as are the associated organizations, personnel, and 
processes. The JTB does not have direct authority over the organizations it is associated 
with yet it is dependent upon those organizations in order to perform its mission. It is due 
to this, that the JTB has become an enterprise, and will be called as such, the JTB 
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Enterprise, throughout this thesis. In the context of this thesis, the term JTB will be used 
to describe the personnel assigned to roles that provide direct support to the JTB Director. 
These personnel support the Director by providing guidance and oversight to the areas of 
authority set forth for the JTB by the Directive. The JTB bridges the gap between the 
deployed elements of the JTB Enterprise and the test sites. There are other areas of the 
JTB Enterprise, which provide the JTB Director information as well. Eor example, the 
JTB employs the use of working groups who perform specific tasking that gives the 
Director information, and that can then be used to develop testing protocols ensuring the 
most effective tests are conducted. 

The end user, in the context of this research, is defined as a person or organization 
that interacts (directly or indirectly) with the JTB. The end user consists of personnel 
deployed to areas where the threat of an lED is heightened. End users are not restricted 
solely to the troops in harm’s way; end users can also be the organizations who provide 
support to the end user. 

Theater support elements are organizations that provide both the end user and the 
JTB with information, which will assist in the counter lED fight. The theater support 
elements are a vital portion of the JTB as these organizations provide access for the JTB 
to the end user as well as a means for the end user to reach out to the JTB. There are also 
times when these organizations will act as the end user and in those cases the terms, 
theater support elements, and end users, can be interchanged. 

The test sites are organizations associated with the JTB Enterprise and consist of 
open-air test centers, laboratories, academic institutions, and modeling and simulation 
laboratories. In some cases, various test sites are used simultaneously for the JTB to 
execute its tasking; therefore, the term test site may refer to one or more of the testing 
organizations. 
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B. THE JOINT IMPROVISED EXPLOSIVE DEVICE TEST BOARD 

In working diligently to test the separate components of an lED defeat system, the 
perception is that opportunities may be missed to coordinate, collaborate, and cooperate. 
Exploiting these opportunities could increase the effectiveness of the information 
available across the JTB Enterprise. If an appropriate collaboration process and tool set 
were available, it is hypothesized that the test centers and supporting research 
organizations would be able to provide better support to the end users. This process 
improvement could increase understanding of the capabilities and limitations for the 
various lED defeat products, and lead to more effective lED mitigation at Eorward 
Operating Bases. It is theorized that an analysis of the JTB Enterprise and its processes 
from the perspective of the end user, will result in better support to the end user. The 
objective is to research the manner of interaction the JTB currently has with the end user, 
and upon uncovering this interaction it is believed the JTB will have a better 
understanding how its products are used. This knowledge could then be used by the JTB 
to evaluate its processes, thus improving the support needed by the end user. 

While the JTB enterprise is involved with several different types of test and 
associated processes, there is one JTB process that is prevalent. The Request for 
Information (REI) process is the most common one employed by the JTB and is at the 
heart of all JTB activities. This research focuses on the REI process. 

C. APPROACH TO RESEARCH 

Determining how the end user uses the products and processes of the JTB 
Enterprise requires an analytical approach. It is believed that an analysis of the JTB, to 
include its organizational structure, processes, and information flow, would yield results 
applicable to both the JTB and the end user. The most efficient way to meet the research 
objectives was by examining the JTB as an Enterprise. The analysis was conducted by a 
three step process. The first step was to attain an overall perspective of the JTBs through 
interviews and academic research. The second step was to structure the information 
gathered by the interviews in accordance with the Department of Defense Architecture 
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Framework (DoDAF) using a software tool with the capabilities for modeling and 
simulation. The third step was to analyze this structure through the modeling and 
simulation capabilities of the software tool. 

The interviews were conducted onsite with various participants within the JTB, as 
well as Subject Matter Experts (SMEs) throughout the JTB Enterprise. The information 
that was gathered through the interview process was critical to complete the analysis and 
resulted in various recommendations to the JTB. The key findings and recommendations 
are given in the hopes of giving the JTB the capability to provide better support to the 
end user. 
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II. LITERATURE REVIEW 


The objective of this research is to provide an end-user perspective of the JTB 
information flow process. The method used to accomplish this objective was to display 
the JTB as an enterprise in accordance with the Department of Defense Architecture 
Framework (DoDAF). This chapter provides a review of information sharing, knowledge 
management, enterprise architecture, and DoDAF. 

A. INFORMATION SHARING 

One of the focal points of this research was to determine how information is 
shared throughout the JTB Enterprise. To provide clarity, a distinction between 
information and knowledge is needed. Information and knowledge are two terms that are 
often used interchangeably; however, information is separate from knowledge, as 
information is data that is given context, and knowledge is information that is given 
meaning; thus information is the heart of knowledge. Information flow can be aided or 
impeded through the use of tools such as the strategy implemented to facilitate 
information sharing, the organizational structure and/or the technical infrastructure. The 
research in this thesis will cover the strategy and organizational structure while the 
technical infrastructure will be examined by a complimentary thesis. 

I. Strategy 

The Department of Defense instituted an Information Strategy in 2007 in response 
to a recommendation from the Quadrennial Review Board of 2006 (U.S. Department of 
Defense, 2007, p. 2). The goal of the strategy is to create an environment within the DoD 
that will promote sharing, achieve an extended enterprise, strengthen agility, and instill 
trust among DoD organizations (U.S. Department of Defense, 2007, p. 5). 
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2. Organizational Structures 

The structure of an organization can dictate how the information flows through 
the organization. There are five components to an organization: the strategic apex (top 
management), the middle line (intermediate managers), the operating core (operators of 
the organization), the technostructure staff (analysts and system designers), and the 
support staff (providers of indirect services to the organization) (Mintzberg, 1981, p. 3). 
Organizations can be structured in five different configurations: a simple structure, a 
machine bureaucracy, a professional bureaucracy, a divisionalized form, and an 
adhocracy (Mintzberg, 1981, p. 4). The machine bureaucracy emphasizes the 
standardization of work for coordination resulting in low skilled yet specialized jobs 
(Mintzberg, 1981, p. 7). The divisionalized form is a group of independent organizations 
loosely joined which is characterized by an incomplete structure (Mintzberg, 1981, p. 8). 
The simple structure, machine bureaucracy, and professional bureaucracy are defined 
later in this section. The focus of this research is on the operating core and the 
technostructure components and the simple structure, professional bureaucracy, and the 
adhocracy as the two components and the three configurations which most closely relate 
to the JTB. 

A simple structure is composed of one large unit with minimal top level managers 
who have oversight of a group of operators who perform the functions of the organization 
(Mintzberg, 1981, p. 5). Key characteristics of a simple structure organization include 
flexibility and highly centralized control. Being a flexible organization allows the 
organization to adapt to a dynamic environment in which the organization may be 
operating; however this can lead to little formalization and little training. The centralized 
control means that all information that flows through the organization flows through the 
strategic apex of the organization (Mintzberg, 1981, p. 5). 

A professional bureaucracy is a configuration arranged by the standardization of 
skills vice the processes, therefore most of the control is given to the personnel who 
perform the tasks, however, the standardization of the skills provides for little flexibility 
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(Mintzberg, 1981, p. 8). The professional bureaucracy relies heavily on its operating core 
which consists of highly-specialized personnel who require a great deal of training and 
indoctrination. This type of configuration operates well in a complex but stable 
environment where personnel require little formalization and coordination as the 
personnel are able to work autonomously (Mintzberg, 1981, p. 8). 

An adhocracy is a configuration that is complex and non-standardized yet fluid. 
Similar to the professional bureaucracy, the adhocracy relies heavily upon specialized 
personnel to perform its duties; however, in this case the specialized personnel 
communicate across domains via the use of integration rules set forth by the organization 
(Mintzberg, 1981, p. 10). It can be defined as adaptable to dynamic situations due to the 
informal nature of communications between the operators of the organization. This 
creates an environment where the specialized personnel must work together in order to 
accomplish tasks as the power of an adhocracy is dispersed throughout the organization 
(Mintzberg, 1981, p. 10). 

3. Collaborative Environments and Organizations 

Information sharing in organizations is typically conducted in a collaborative 
environment. Collaboration is the efficient and effective manner in which organizations 
work together internally and externally and is practiced at all levels of an organization 
(Beyerlein, 2003, p. 13). A collaborative organization is designed to allow information to 
flow easily throughout the organization. Benefits of a collaborative environment include 
empowered personnel, as they do not require direct supervision, improved processes, as 
personnel take it upon themselves to solve problems, and better support to the end user, 
as personnel and end users collaborate which maximizes support (Beyerlein, 2003, p. 25). 

Collaborative organizations are built upon the ten principles listed in Table 1. 
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Table 1. Principles of Collaborative Organizations (From Beyerlein, 2003, p. 34) 


Focus collaboration on achieving business results 


Align organizational support systems to promote ownership 


Articulate and enforce “a few strict rules” 


Exploit the rhythm of convergence and divergence 


Manage complex tradeoffs on a timely basis 


Create higher standards for discussions, dialogue, and information sharing 


Foster personal accountability 


Align authority, information, and decision making 


Treat collaboration as a disciplined process 


Design and promote flexible organizations 


Three of the principles listed in Table 1 will be elaborated upon in order to keep 
within the scope of this research. The third principle, articulate and enforce “a few strict 
rules,” involves developing governance for the organization thus providing direction and 
guidance to members of the organization. The “few strict rules” should not constrain or 
inhibit personnel in performance of their duties. The rules should be a set of parameters 
which would provide personnel enough freedom to accomplish tasking, yet structured to 
align with the strategic goals of the organization (Beyerlein, 2003, p. 39). The sixth 
principle, create higher standards for discussion, dialogue, and information sharing, gives 
the organization the ability to discuss and consider alternatives to increasingly complex 
problems. Solving complex problems in an unpredictable environment is possible in a 
collaborative organization since the information needed to make decisions is both 
available and accessible (Beyerlein, 2003, p. 43). The ninth principle, treat collaboration 
as a disciplined process, promotes the ability to continually monitor and improve the 
process. This increases the likelihood that all stakeholders involved in the process have 
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common information. Therefore, the decisions made based on the common information 
are more apt to be trusted at all levels of an organization since the decision is the result of 
a collaborative effort (Beyerlein, 2003, p. 49). 

B. ENTERPRISE ARCHITECTURE 

An enterprise is a group of associated organizations and/or activities that includes 
the people, information, and technology that provide a service to a customer or end user. 
Enterprises are structured in different ways that depend upon the number of 
organizations, people, and processes involved which are needed to allow the enterprise to 
function. The structure of an enterprise is its architecture and within this architecture are 
the guiding principles upon which the organization was founded (Minoli, 2008, p. 54). 
The principles may or may not be apparent by the architecture of the enterprise. 
Principles that are not explicitly stated in the architecture would have been used to 
develop the framework. The framework is the tool used to describe the enterprise’s 
architecture. There are many accepted frameworks in use around the world; this thesis 
will use the DoD Architecture Framework (DoDAF). 

An enterprise architecture framework is a means to represent all aspects of the 
enterprise. To accurately describe the enterprise the framework must have an 
overarching set of standards or a strategy to govern the interactions associated with the 
enterprise (Minoli, 2008, p. 70). The governance of the enterprise should be generated 
and enforced by a Chief Information Officer/Chief Technology Officer (CIO/CTO) and 
should cover the principles in Table 2, which has been legislated by the Clinger-Cohen 
Act (1996). 
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Table 2. Enterprise Architecture Principles (From Minoli, 2008, p. 64) 


Architectures must be appropriately scoped, planned, and defined based on the intended use _ 

Architectures must be compliant with the law as expressed in legislative mandates, executive orders, 
federal regulations, and other federal guidelines. _ 

Architectures should facilitate change _ 

Architectures set the interoperability standard _ 

Architectures provide access to the information but must secure the organization against unauthorized 
access _ 

Architectures must comply with the privacy act of 1974 _ 

Enterprise architectures must reflect the agency’s strategic plan _ 

Enterprise architectures coordinate technical investments and encourage the selection of proven 
technologies _ 

Architectures continuously change and require transition _ 

Architectures provide standardized business processes and common operation environments _ 

Architecture products are only as good as the data collected from subject matter experts and domain 
owners. _ 

Architectures minimize the burden of data collection, streamline data storage, and enhance data access _ 

Target architectures should be used to control the growth of technical diversity _ 

When developing the enterprise architecture the CIO/CTO can base the 
governance of the enterprise on the ideas covered in Table 3. 

Table 3. Enterprise Architecture Development Considerations (From Minoli, 2008, p. 71) 

Description of the purpose and value of an enterprise architecture 

Description of the relationship of the enterprise architecture to the agency’s strategic vision and plans 

Description of the relationship of the enterprise architecture to capital planning, enterprise engineering, and 
program management _ 

Translation of business strategies into enterprise architecture goals, objective, and strategies _ 

Commitment to develop, implement, and maintain an enterprise architecture _ 

Identification of enterprise architecture compliance as one criterion for new and ongoing investments _ 

Overview of an enforcement policy _ 

Security practices to include certification and accreditation _ 
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The CIO/CTO should also consider the enforcement policy questions in Table 4. 


Table 4. Enterprise Architecture Policy Development Questions (From Minoli, 2008, p. 

71) 

How and when will projects submit project plans to be reviewed for enterprise architecture compliance? 

Who will be responsible for compliance assessment or justification of waivers? _ 

How will compliance and noncompliance be documented and reported? _ 

How will outstanding issues of noncompliance be resolved or wavers be processed and approved? _ 

Who will be responsible for processing, authorizing, and reassessing waivers? _ 

What will be the content and format of waiver submissions? _ 

If a waiver is granted, how will projects achieve compliance in the future? _ 

What are the ramifications if a noncompliant project is not granted a waiver (e.g., funding or deployment 
restrictions)?_ 


There are two complimentary views of an enterprise architecture. The first is that 
an enterprise architecture provides the organizing logic for processes and the information 
technology infrastructure that correspond to the integration and standardization 
requirements of the organizations operating model (Ross, 2006). The second is that an 
enterprise architecture is a blueprint that defines the structure and operation of an 
organization with the intent of determining the most effective employment of the 
organizations resources (Ross, 2006). Figure 1 provides an example of a way to organize 
an enterprise based upon the amount of integration and standardization required for the 
enterprise to meet its goals. 
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Coordination 

• Shared customers, products, or 
suppliers 

• Impact on other business unit 
transactions 

• Operationally unique business units 
or functions 

• Autonomous business management 

• Business unit control over business 
process design 

• Shared customer/supplier/product 
data 

• Consensus processes for designing 

IT infrastructure services: 

IT application decisions made in 
business units 

Unification 

• Customers and suppliers may be 
local or global 

• Globally integrated business 
processes often with support of 
enterprise systems 

• Business units with similar or 
overlapping operations 

• Centralized management often 
applying functional/process/business 
unit matrices 

• High-level process owners design 
standardized processes 

• Centrally mandated databases 

• IT decisions made centrally 

Diversification 

• Few, if any, shared customers or 
suppliers 

• Independent transactions 

• Operationally unique business units 

• Autonomous business management 

• Business unit control over business 
process design 

• Few data standards across business 
units 

• Most IT decisions made within 
business units 

Replication 

• Few, if any, shared customers 

• Independent transactions aggregated 
at a high level 

• Operationally similar business units 

• Autonomous business unit leaders 
with limited discretion over processes 

• Centralized (or federal) control over 
business process design 

• Standardized data definitions but 
data locally owned with some 
aggregation at corporate 

• Centrally mandated IT services 


Low High 


Business process standardization 


Figure 1. Business Process Integration vs. Business Process Standardization 

(From Ross, 2006, p. 29) 

1. Department Of Defense Architecture Framework 

The Department of Defense Architecture Framework (DoDAF) was developed to 
provide a set of architecture techniques that will assist in supporting the decision makers 
(U.S. Department of Defense, 2007, Vol. 1, p. 5). It is designed for all major DoD and 
military organizations as a means to offer structure and give a representation of how an 
organization interacts internally and with other organizations (U.S. Department of 
Defense, 2007, Vol. 1, p. 5). DoDAF employs viewpoints that cover functional areas 
related to the architecture of an enterprise. The eight different viewpoints available 
within DoDAF are described in Table 5. 
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Table 5. DoD Architecture Framework Viewpoint Description (From U.S. Department of 

Defense, 2007, Vol. 1, p. 21-22) 


Viewpoint 

Description 

All 

Contains overarching aspects of the architecture as related to all of the viewpoints 

Capability 

Articulates the capability requirements, the delivery timing, and the deployed capability 

Data and 

Information 

Articulates the data relationships and alignment structures in the architecture content for 
the capability and operational requirements, system engineering processes, and systems 
and services 

Operational 

Includes the operational scenarios, activities, and requirements that support capabilities 

Project 

Describes the relationships between operational and capability requirements and the 
various projects being implemented 

Services 

The design for solutions articulating the Performers, Activities, Services, and their 
Exchanges, providing for or supporting operational and capability functions 

Standards 

The design for solutions articulating the Performers, Activities, Services, and their 
Exchanges, providing for or supporting operational and capability functions 

Systems 

The design for solutions articulating the systems, their composition, interconnectivity, 
and context providing for or supporting operational and capability functions 


Figure 2 is a visual representation of the multiple DoDAF viewpoints and the 
relationships between them. 



D 

fi) 

B) 

w 

fi) 

3 

Capability Viewpoint 

TJ 

> 

< 

S' 

< s 

<D Q. 

S - 

Q. 

fi) 

Q. 

U) 

Operational Viewpoint 

o 

“S' 

o 

< 

TS 

O 

5’ 

2. 

2. o 

- i 

fi) 

< 

S' 

€ 

■o 

Services Viewpoint 

S' 

€ 

■o 

o 


o' 

3 

o 

5' 

Systems viewpoint 

3 


Figure 2. DoD Architecture Framework Viewpoint relationships (From U.S. 

Department of Defense, 2007, Vol. 2, p. 140) 
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As both an organization and an enterprise it is logical to structure the JTB in 
accordance with DoDAF, however only Operational Viewpoints and System Viewpoints 
were produced as part of the research for this thesis. 

a. Operational Viewpoints 

Operational viewpoints are used to describe a DoD organization by 
graphically depicting the tasks, activities, and operations performed by that organization. 
Developing operational viewpoints can assist the organization by linking functional 
requirements to the organization’s activities. There are nine models associated with 
Operational Viewpoints as described in Table 6. 

Table 6. Operational Viewpoint Models (From U.S. Department of Defense, 2007, Vol. 2, 

p. 162) 


Model 

Description 

OV-l: High-Level 

Operational Concept Graphic 

The high-level graphical/textual description of the operational concept 

OV-2: Operational Resource 
Flow Description 

A description of the Resource Flows exchanged between operational 
activities 

OV-3: Operational Resource 
Flow Matrix 

A description of the resources exchanged and the relevant attributes of the 
exchanges 

OV-4; Organizational 
Relationships Chart 

The organizational context, role or other relationships among 
organizations 

OV-5a: Operational Activity 
Decomposition Tree 

The capabilities and activities (operational activities) organized in a 
hierarchal structure 

OV-5b; Operational Activity 
Model 

The context of capabilities and activities (operational activities) 
and their relationships among activities, inputs, and outputs; 

Additional data can show cost, performers or other pertinent information 

OV-6a: Operational Rules 
Model 

One of three models used to describe activity (operational activity). It 
identifies business rules that constrain operations 

OV-6b: State Transition 
Description 

One of three models used to describe operational activity (activity). It 
identifies business process (activity) responses to events (usually, very 
short activities) 

OV-6c: Event-Trace 
Description 

One of three models used to describe activity (operational activity). It 
traces actions in a scenario or sequence of events 
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Once these models are developed they can be used to describe an organization in 
a simple logical architecture. This description can be used by the organization’s decision 
makers to assist in developing requirements, operating concepts, and processes. 

b. System Viewpoints 

Systems Viewpoints are used to describe how the systems an organization 
uses support the organization’s functions. The System Viewpoint models are designed to 
associate the operational viewpoint activities and display the exchange of information 
between those activities. The thirteen System Viewpoint models are described in Table 

7. 


Table 7. System Viewpoint Model (From U.S. Department of Defense, 2007, Vol 2, p. 

201 ) 


Models 

Descriptions 

SV-1 Systems Interface 
Description 

The identification of systems, system items, and their interconnections 

SV-2 Systems Resource Flow 
Description 

A description of Resource Flows exchanged between systems 

SV-3 Systems-Systems Matrix 

The relationships among systems in a given Architectural Description. It can 
be designed to show relationships of interest, (e.g., system-type interfaces, 
planned vs. existing interfaces). 

SV-4 Systems Functionality 
Description 

The functions (activities) performed by systems and the system data flows 
among system functions (activities). 

SV-5a Operational Activity to 
Systems Function Traceability 
Matrix 

A mapping of system functions (activities) back to operational activities 
(activities). 

SV-5b Operational Activity to 
Systems Traceability Matrix 

A mapping of systems back to capabilities or operational activities (activities). 

SV-6 Systems Resource Flow 
Matrix 

Provides details of system resource flow elements being exchanged between 
systems and the attributes of that exchange. 

SV-7 Systems Measures 

Matrix 

The measures (metrics) of Systems Model elements for the appropriate 
timeframe(s). 

SV-8 Systems Evolution 
Description 

The planned incremental steps toward migrating a suite of systems to a more 
efficient suite, or toward evolving a current system to a future implementation. 

SV-9 Systems Technology & 
Skills Forecast 

The emerging technologies, software/hardware products, and skills that are 
expected to be available in a given set of time frames and that will affect 
future system development. 

SV-lOa Systems Rules Model 

One of three models used to describe system functionality. It identifies 
constraints that are imposed on systems functionality due to some aspect of 
system design or implementation. 

SV-lOb Systems State 

Transition Description 

One of three models used to describe system functionality. It identifies 
responses of systems to events. 

SV-lOc Systems Event-Trace 
Description 

One of three models used to describe system functionality. Identifies system- 
specific refinements of critical sequences of events described in the OV. 
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III. METHODOLOGY 


A. INTRODUCTION 

To meet the thesis objectives the researcher needed to identify, capture, and 
understand the interaction between the end user and the JTB. This was completed by 
performing research, including conducting a literature review (Chapter II), conducting 
interviews with process participants, using an architecture development tool to represent 
this information, and using the software tool to analyze the interactions. 

B. INTERVIEWS WITH SUBJECT MATTER EXPERTS 
I. Developing the Interview Questions 

a. Development of Questions 

The questions for the interviews were developed to capture the most 
information in an hour, so as not to disrupt the work schedules of participants. Interview 
questions were developed through a dialogue between the researcher and the thesis 
advisors. Final questions were selected in order to ensure the participants’ answers 
would be focused upon the information sharing processes within the JTB enterprise. 

b. Interview Questions 

Table 8 contains the questions that were asked of the participants with 
respect to information flow. 

Table 8. Information Flow Questions 

Which nodes/activities within the JIEDDO Test Board (JTB) do you interact 

with? _ 

How often do you interact with these nodes/activities? 

(DailyAV eekly/Monthly/Other) _ 

What type of information is passed from you to other nodes within the JTB? 

What type of information is passed to you from other nodes within the JTB? _ 

How do you pass the information to other nodes within the JTB? _ 

How do you receive information from other nodes within the JTB? 
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Table 9 contains the questions that were asked of the participants with 
respect to information usage. 


Table 9. Information Usage Questions 


Can you sketch the information flow within the JTB from your vantage point? 

How do other nodes within the JTB communicate? 

What type of products do you produce or publish? 

What type of products do you obtain or use? 

Do you use SIPRnet? 

How often do you access SIPRnet? 

Do you access the JTB SIPRnet web portal? 

How often do you access the portal? 

What information do you access on the portal? 

Who generates the information on the portal? 

What information do you need on the portal that is currently not there but available 
elsewhere? (i.e.. Testing site portals) 

Have you received training on tbe portal? 

Did training include a review of the information available on tbe portal? 

Did the training include procedures of how to access information on the portal? 

How do you use the NIPRnet? 

How is this process efficient? What is missing? 

How is this process inefficient? What is missing? 


The questions in Table 10 were used to refine the information provided 
thus assisting to produce accurate models. 

Table 10. Information Refinement 

Process: What happens inside this activity/node? _ 

Input: What documents, online-data, or discussions do you need to begin this process? 
What information, very roughly, do these give you? 

Output: What documents, information systems, or discussions does this node produce? 

Trigger: What triggers communication with this node: a schedule and/or an event? _ 

Periodicity: Is this node performed continuously or on-demand? _ 

Periodicity: How active is this node (_times per_hr/day/wk/mo/yr)? Please state a 

range from low to high frequency? _ 

Duration: How long does it take to execute this node? _ 

Flow/Precedence: Does this node happen in parallel with other nodes? Which nodes? 
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2 . 


The Interview Process 


The research process used for this thesis included receiving Institutional Review 
Board approval, determining the interview participants, and developing the interview 
questions. 


a. The Institutional Review Board 

The methods used to gain information were in accordance with the Naval 
Postgraduate School Internal Review Board. 

b. Participant Selection 

It was determined that conducting interviews with members of the JTB 
Enterprise, to include subject matter experts (SME) from organizations within or 
associated with the JTB, would be able to provide the best description of the current 
processes of the JTB. All participants interviewed were recommended by the JTB as 
each participant had experience and knowledge about different aspects of the JTB 
Enterprise. 


c. Interview Procedure 

The researcher met with participants in a quiet setting beneficial to 
conducting an interview. The period of time spent with each participant varied, due to 
the participants’ subject area and knowledge of the JTB as well as the participants’ 
willingness to talk. The interview took an average of one hour to complete, however 
some interviews lasted longer due the nature of the participant’s expertise. Interviews 
were recorded (when permitted) to prevent any loss of information provided by the 
participant. These interviews proved crucial in capturing critical information on each 
participant’s organization or activity. In addition, several of the participants had recently 
been deployed to Afghanistan and Iraq where they served as convoy leaders and faced 
lED threats. These participants were interviewed to determine how the JTB and its 
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products and services are utilized by the end users. Interviews were conducted in person, 
which required travel to the various organizations and testing sites associated with the 
JTB enterprise. 

The researcher traveled to interview participants at the various locations 
within the JTB Enterprise. Interviews were conducted with the participant(s) and 
researcher seated in a quiet room with the door closed. Participants were informed about 
the nature of the research and given consent forms to sign (the participants were assured 
that names would not be used). Participants were also informed that if there were any 
questions which caused any undue stress they did not need to answer. Once the forms 
were signed participants were asked the questions on information flow in Table 8 and 9. 
After answering those questions the participant was then asked the questions in table 10, 
depending upon the progress of the research at the time the participant were shown 
representative models of the JTB Enterprise and the JTB REI Process, and asked to 
comment and/or correct the model. 

d. Transcription 

Participants were asked if the interview could be recorded; most agreed, 
however some did not. Some of the interviews were transcribed to ensure that all 
applicable information provided by the participants was used. 

3. Obstacles to the Interview Process 

Several obstacles had to be overcome throughout the interview process. In one 
instance the interview was conducted in a secure facility that restricted the use of 
personal electronic devices so the interview could not be recorded. In other instances 
some participants answered with short simple answers, such as merely a “yes” or “no,” 
providing little insight. Another obstacle was that some participants declined to be 
recorded; this was either due to the participant’s status as a contractor, or to the 
participant’s unease with the interview process. In all interviews, time was taken 
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immediately after the interview concluded to write down information the participant had 
provided during the interview to ensure the maximum amount of information was 
retained. 

C. IMPLEMENTING DODAF 

It became evident that in order to analyze the JTB from the end user perspective, 
the JTB Enterprise would not only need to be documented but the results of the interview 
process would need to be displayed in a manner that would provide all personnel 
associated with the JTB the means to fully understand the enterprise. To accomplish this, 
the objective was to graphically display the JTB Enterprise and the associated processes 
using the Department of Defense Architecture Eramework (DoDAE). Results of the 
interview process were entered into a software tool, OpenText’s Provision. Provision 
provides the capability to model the entire JTB Enterprise, and to simulate any process 
models developed. Training was received on the use of software tool (Provision), which 
included how to enter data collected during the interviews into the tool in order to 
develop the Operational Viewpoints and System Viewpoint. 

I. Developing Models 

The DoDAE models chosen to represent the JTB Enterprise consist of three 
Operational Viewpoints (OV-1, OV-4, and OV-6) and one System Viewpoint (SV-1). 
These four models best describe the JTB Enterprise, keeping within the scope of the 
research. The OV-1 and the OV-4 were completed by using the information gathered 
during the interview process as an input to the software tool. The OV-1 was developed to 
show a broad overview of a JTB Process and how the end users and the JTB conduct the 
JTB REI Process. The OV-4 was developed to depict the relationships and interactions 
the JTB has with the organizations included in the JTB Enterprise. The OV-6 was 
developed and refined then used to model the JTB REI Process. The JTB REI Process is 
not the only testing process the JTB executes, however it was selected as the process to 
represent the JTB Enterprise as it is performed within the JTB Enterprise. Other 
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processes, over which the JTB has some authority in accordance with the DoD Directive 
2000.19, include JIEDDO initiatives; however, those processes involve organizations 
outside the scope of the research. The SV-1 was developed to represent the users of the 
JTB portal. The SV-1 was developed by using the participant’s answers to the interview 
questions. 

2. Simulating the OV-6 Model 

Once the models were developed additional information was obtained through the 
JTB Portal. The information obtained from the JTB Portal consisted of statistical data on 
the JTB RFI Process. The statistical analysis entailed gathering the number of RFIs the 
JTB received in the year 2010. Each RFI was examined, in terms of the time taken to be 
resolved and the manner of resolution. This information was used in the OV-6 to refine 
the sources, destinations, activities and decision points of the OV-6. The model could 
then be accurately simulated. The parameters used to run the simulation consisted of one 
hundred runs times over a one year time frame and was based on the recommendations of 
one of the thesis advisors. These parameters allowed the model to be executed multiple 
times of the course of a year, which would provide assistance to determine the flow of 
information through the JTB Enterprise and display activities where the information may 
be impeded or delayed. 
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IV. RESULTS 


Through the interviews and statistical research it was discovered that the JTB is 
an Enterprise contained within the larger JIEDDO Enterprise. This is significant since 
many of the roles associated with enterprises (such as human resources or payroll) are 
administered by the parent JIEDDO Enterprise; this makes the JTB Enterprise unique as 
it only needs to focus upon its tasking. The answers given in the interview process 
provided the data needed to develop the DoDAE models which have been designed to 
provide situational awareness to the JTB regarding the flow of information and the end 
user role in the enterprise. 

A. OPERATIONAL VIEWPOINT (OV-1) OF THE JOINT lED DEFEAT 

TEST BOARD REQUEST FOR INFORMATION PROCESS 

The purpose of an Operational Viewpoint 1 (OV-1) is to give an overview as to 
how a process or organization is aligned and display its lines of communication. Figure 3 
is an OV-1 depicting the top-level flow of information during the JTB RFI Process as it 
passes through the major activities in the JTB Enterprise. Each of the organizations 
included in the OV-1 has the ability to generate a Request for Information (RFI) should 
an event occur or these organizations need information required to conduct mission 
tasking. This research is primarily focused on the end users, which can be any of the five 
organizations displayed on the right side of Figure 3. The Theater Operating Forces, such 
as US Forces Iraq and the Multinational Forces-Afghanistan, are the final end users of the 
JTB process and products. 

The JTB can have either a direct or indirect effect upon these end users. A direct 
effect occurs when these end users generate an RFI. An RFI is generated by submitting 
the RFI through the Theater Support Web Tool (TSWT) or by making contact with either 
JTF Paladin or JTF Troy and having either of those two organizations generate an RFI for 
them. Once generated, the RFI follows the information flow as illustrated in Figure 3, 
passing once again through either JTF Paladin or JTF Troy to the end user. 
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Figure 3. JTB Overview (OV-1) 
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JTF Paladin and JTF Troy work with forces within their respective theater of 
operations to provide training or develop processes and procedures. These processes and 
procedures are then implemented in the field by Battalion Electronic Warfare Officers 
(EWO) to assist in the protection of US and Coalition Eorces. Under these circumstances 
JTE Paladin and JTE Troy act as the end user. In these situations an REI generated by 
JTE Paladin or JTE Troy is also terminated at JTE Paladin and/or JTE Troy. The 
information from the REI could then be passed to the operating forces in theater, which is 
an example of a situation where the JTB has an indirect effect upon the theater operating 
forces. 

The Combined Theater Electronic Warfare Command Center (CTEWCC) is an 
integral and focal point of the REI process. CTEWCC acts as a filter for REIs and other 
CIED information as it collects inputs from all relevant organizations within the AOR 
and provides prioritization of testing requirements to the JTB. CTEWCC is also tasked 
with assisting in conflict resolution. If conflicts occur between any of these theater 
organizations that cannot be resolved, the CTEWCC Commander has the authority to 
make a final determination. The JTB will not accept any test priorities from CENTCOM 
organizations without first coordinating with CTEWCC. The key for CTEWCC is to 
build relationships with the commanders or officers in charge of the theater task forces 
and coordinate a unity of effort between them. This in turn will provide additional 
support when they request it (for example, to ghostwrite REIs or even write them 
completely when they don't have time). In this manner CTEWCC is the Supporting 
Command whilst JTE Paladin and JTE Troy along with the other end users are the 
Supported Commands. 

Once an REI has cleared through CTEWCC it is forwarded to the JTB, who 

determines method of testing which is to be utilized to resolve the REI. Three general 

methods, or types, of testing are used for REI resolution: laboratory testing, modeling and 

simulation testing, and open air testing. At this point it is up to the JTB to determine 

which method is most beneficial; in some cases more than one method is used. Once the 

method of testing is assigned to a specific REI it is then scheduled, planned, and tested by 

that organization. Upon completion of testing a test report is written and approved by the 
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testing organization and then posted to the JTB web portal. This portion of the proeess is 
very well organized and effieient and has led to the sueeessful testing of over three 
hundred RFIs, adhering to the guidanee set forth for the JTB in the DoD Direetive whieh 
states it will “synehronize and eoordinate all JIEDDO eounter lED testing efforts.” 

Results of the testing are eompiled, and a test report is written and posted to the 
JTB Portal, loeated on the SIPRnet. Upon uploading the test report to the portal, the 
Knowledge Information Network Group (KING) uses the data in the report to generate a 
produet for the end users whieh displays the effeetiveness of the CIED equipment that 
was tested. Test reports and other related JTB produets available on the JTB Portal ean 
be downloaded and utilized by the different theater support elements. It should be noted 
that information on the JTB Portal is pulled by the user, rather than pushed to all parties 
involved. 

B. THE JTB ENTERPRISE 

Using the results of the interview proeess a DoDAE model was developed using 
the Provision software tool. This Operational View is an organizational model, more 
eommonly known as an OV-4. The OV-4 eneompasses and displays the JTB as an 
Enterprise displaying the organizations and aetivities whieh the JTB has either direet 
authority over, or has built a strong relationship with, to aeeomplish the mission of the 
JTB. 


1. Structure of the JTB 

The Joint lED Defeat Test Board (shaded gray and green in Eigure 4) is 
loeated in three loeations aeeessible to the Washington, DC Metro area: Crystal City, VA, 
Alexandria, VA (ATEC South faeility), and Aberdeen, MD (ATEC North faeility); the 
majority of the personnel are loeated in Alexandria, VA. The JTB organization follows a 
hierarehieal staff strueture with a Chairperson and a Direetor and then is further 
segmented into various funetional areas, sueh as the Support and the Operations 
divisions. The JTB operates within and aeross these different funetional areas 
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necessitating a robust, knowledge dependent organization. In order to fulfill the many 
duties assigned to the JTB, contractors have been hired to provide specialized assistance 
and expertise. 

The JTB also employs the use of working groups (shaded orange in Figure 
4). These working groups consist of subject matter experts (SMEs) who collaborate and 
provide recommendations to the JTB Director, such as testing protocols. There are 
currently eight working groups; Knowledge Management, Information Technology, 
Threats, Test Operations, Advanced Communications, Foreign Disclosure, and Electronic 
Attack Clearance. The working groups are also consistent with the functional areas 
conducted within the JTB. 
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2. Organizations Associated with the JTB 

Many organizations are associated with the JTB. Figure 4 is not all inclusive, as 
the JTB has the ability to use a multitude of resources in order to comply with its tasking. 
In Figure 4 the organizations associated with the JTB are linked to the JTB Director with 
a dashed line, the dashed line represents the relationship between the JTB and the various 
organizations as a working relationship rather than a hierarchical relationship. Of these 
organizations with ties to the JTB some are used more often than others, yet all are 
important as each organization provides a specific asset which the JTB can utilize, thus 
maximizing the effort while supporting the end user. 

a. Testing Agencies 

The JTB employs the use of many different testing agencies which include 
open-air testing, laboratory testing and modeling and simulation organizations. Each 
organization offers a different means for the JTB to accomplish its mission. The JTB 
counts on these organizations for specific tasking; it is the specificity that assists the JTB 
in decreasing redundancy in testing which is directed in the DoD directive. The use of 
multiple testing agencies also gives the JTB flexibility to conduct many concurrent tests. 

(1) Open Air Testing Facilities. Open air testing plays a vital role 
in JTB’s ability to provide quality products to the end user. The open air testing sites 
employed by the JTB include but are not limited to Yuma Proving Grounds (YPG), 
Naval Air Weapons Station China Lake (China Lake), and White Sands Missile Range 
(WSMR). Each of these sites has the ability to replicate any environment JTB testing 
requires including electromagnetic, temperature and urban/rural environments. These 
open air sites also have the ability to manipulate the test environment in order to simulate 
the true environment where the result of the test will be used. Testing environments are 
developed in accordance with specific criteria obtained from a Request for Information 
(RLI), a vendor’s specifications, or test protocols set forth by the JTB. 

(2) Laboratories and Universities. Laboratories and universities 
offer the JTB a means to conduct testing in a controlled environment. Laboratories offer 
the JTB the ability to test not only equipment but protocols and/or procedures as well. 
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This is advantageous to the JTB and the end user since this testing can often be conducted 
quickly and at a lower cost than open air testing. Testing at the different laboratories and 
universities may also consist of modeling and simulation (M&S). The ability to develop 
and execute models affords the JTB another avenue for effective testing at a lower cost 
than open air testing. 

b. Theater Elements 

(1) End User. The end user (shaded light brown in Figure 4) is the 
war fighter. In this sense the end users are the members of the Armed Services who, by 
the nature of their work, are in close proximity to the lED threat. The end users utilize 
JTB products which are passed to them via Battalion Headquarters, turnover of 
equipment with other users, or other theater operational support elements. The end users 
receive the JTB products and put them into practice when operating in a region where the 
possibility of encountering an lED is elevated. The end users have their lives on the line 
and are dependent upon the effectiveness, as well as the availability of, the products 
produced by members of the JTB. 

(2) Theater Operational Support. Theater operational support 
elements include the different organizations that fall within the JTB’s scope of 
operations. The JTB relies on many organizations to ensure testing conducted is relevant 
to the end user as well as ensure the end user has the proper JTB products in order to 
succeed. One such organization is the Combined Theater Electronic Warfare Control 
Center (CTEWCC), described in section A of this chapter. Other theater support 
elements consist of JTF Paladin and JTF Troy and the JTB Forward Operating and 
Assessment (FOA) teams. Each of these organizations works with both the end users and 
the JTB to ensure testing is relevant and the priority of the test is understood. These 
elements also have the capability to submit RFIs to the JTB through the TSWT. 
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C. THE JTB RFI PROCESS 

Many processes are incorporated within the JTB while accomplishing its mission, 
such as payroll and other monetary processes, however, the scope of this research was to 
focus upon the end user. The JTB RFI Process was chosen to represent the interactions 
of the JTB Enterprise as it is includes the end user. The JTB RFI Process model was 
developed to be displayed as a DoDAF OV-6 in order to be simulated, and simulation 
results are intended to provide an accurate representation of the process. Figures 5 
through 8 depict the JTB RFI process. 
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Figure 5. 
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Figure 8. The JTB RFI Process 
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Activities and Decision Points 


The JTB RFI Process (shown in Figures 5-8) consists of nineteen activities. Each 
activity represents an action taken by an organization within the JTB enterprise. The 
organizations are arranged horizontally while the sequences of the process have the 
ability to move both horizontally and vertically. Tables 11 and 12 describe the activities 
and decision points contained within the OV-6. 

a. JTB RFI Process Activities 

The JTB RFI Process contains 19 activities that are described in Table 11. 


Table 11. JTB RFI Process Activities 


Activity 

Description 

Generate RFI 

Once an end user or theater support personnel have determined a need 
for information, the Theater Support Web Tool (TSWT) is utilized in 
order to generate a request for information. 

RFI Status: Open 

The status of an RFI becomes open once it has been submitted through 
the TSWT. 

Submit Documentation 

Proper documentation is located and posted to the JTB Portal and sent 
to generator of RFI 

Compatibility Test 
Planning 

During the test planning phase information is gathered, based upon RFI 
input, and test is scheduled and planned based upon current protocols. 

Compatibility Test 
Execution 

Execution of compatibility testing occurs once the test plan has been 
developed and permission has been granted. 

Compatibility Test 
Report 

Upon completion of compatibility testing, an initial quick-look is 
generated and submitted to all subscribers of the RET Also an official 
test report is drafted and submitted for approval. Once approved the 
test report is posted to the JTB SIPRnet web portal. 

Performance Test 
Planning 

During the test planning phase information is gathered, based upon REI 
input, and test is scheduled and planned based upon current protocols. 
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Activity 

Description 

Performance Test 
Execution 

Execution of performance testing occurs once the test plan has been 
developed and permission has been granted. 

Performance Test 

Report 

Upon completion of performance testing, an initial quick-look is 
generated and submitted to all subscribers of the RET Also an official 
test report is drafted and submitted for approval. Once approved the 
test report is posted to the JTB SIPRnet web portal. 

Lab Test Planning 

During the test planning phase information is gathered, based upon REI 
input, and test is scheduled and planned based upon current protocols. 

Lab Test Execution 

Execution of laboratory testing occurs once the test plan has been 
developed and permission has been granted. 

Lab Test Report 

Upon completion of laboratory testing, an initial quick-look is 
generated and submitted to all subscribers of the REI. Also an official 
test report is drafted and submitted for approval. Once approved the 
test report is posted to the JTB SIPRnet web portal. 

M & S Test Planning 

During the test planning phase information is gathered, based upon REI 
input, and test is scheduled and planned based upon current protocols. 

M & S Test Execution 

Execution of modeling and simulation testing occurs once the test plan 
has been developed and permission has been granted. 

M & S Test Report 

Upon completion of modeling and simulation testing, an initial quick- 
look is generated and submitted to all subscribers of the REI. Also an 
official test report is drafted and submitted for approval. Once 
approved the test report is posted to the JTB SIPRnet web portal. 

Post Test Report to JTB 
Portal 

Once testing is completed the testing agency posts the report to the JTB 
Portal in order to provide information to the JTB Enterprise. 

JTB review 

JTB inputs test report data to database 

Theater Support 

Review 

Theater support elements review and disseminate information to end 
users 
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Activity 

Description 

Utilization 

End users apply results and modify TTPs based upon new information 


b. JTB RFI Process Decision Points 


The process also contains four decision points, which are described in 

table 12. 


Table 12. JTB RFI Process Decision Points 


Decision Point 

Description 

Is RFI Valid? 

CTEWCC determines the validity of the request. If the RFI is deemed 
to be a valid request it is then sent to the JTB for further determination 
of the manner in which the RFI will be resolved. 

Does RFI Require 
Testing? 

This is determined by JTB personnel. A no decision leads to the RFI 
being resolved by sending documentation to the generator of the RFI, 
for example the documentation could be a previously published Test 
Report or a publication from the manufacturer. A no decision could 
also lead to a study conducted in an academic setting. A yes answer 
leads to other decision points to determine the type of testing. If more 
information is required to determine testing type or procedures, the RFI 
originator is contacted in order to answer questions. 

What type of testing is 
needed? 

This decision is used to determine how the RFI will be resolved. The 
options include; open air testing, laboratory testing, or modeling and 
simulation. 
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Decision Point 

Description 

Compatibility/ 
Performance testing 

If it is decided that open air testing will be conducted the RFI is then 
forwarded to an open air facility to conduct either compatibility or 
performance testing. This decision is determined by the information 
given in the RFI. 


2. Sequence of the JTB RFI Process 

The process is started, once a need for information is determined by either an end 
user or a member of a theater support system. An RFI is generated within the Theater 
Support Web Tool (TSWT) on the SIPRnet (which was considered to be accessible by all 
participants involved in the interview process). Upon submitting the RFI the status is 
switched to “Open” and sent to CTEWCC for review as CENTCOM has mandated that 
all JTB REI requests from CENTCOM AOR will be passed through and approved by 
CTEWCC. CTEWCC then determines the validity of the request. If the REI is deemed 
to be a valid request it is forwarded to the JTB for further determination of the manner in 
which the REI will be resolved. In this way CTEWCC acts as a filter between the JTB 
and the theater support systems/end users. 

The JTB receives the REI and its priority (assigned by CTEWCC) via notification 
by the TSWT. JTB personnel determine how the REI will be resolved. If it is decided 
that testing is not required, documentation (such as a prior test report and/or a 
manufacturer’s manual) is sent to the generator of the REI. If the REI requires testing it 
is forwarded to one of the test agencies, which leads to other decision points to determine 
the type of testing. The “else” decision is used in case the REI is deemed invalid and thus 
closed. If more information is required to determine testing type or procedures, the REI 
originator is contacted to obtain clarification. 

The next decision is to determine if the REI will be resolved using an open air test 
range, a lab, or modeling and simulation. In any of the three cases the testing has been 
broken down to three essential activities. The first is the planning portion of the testing. 
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The test agency will plan and schedule the test in accordance with protocols set forth by 
the JTB and the RFI. The test sites use this time to reach out to the RFI generator or 
CTEWCC should any questions arise. This is an invaluable step as it ensures the testing 
is planned and executed to provide the best support the end users. The next two steps of 
the RFI process (Test Execution and Test Report) are performed by the test agency, 
however the JTB is heavily involved as it monitors and synchronizes the testing during a 
weekly video teleconference (VTC) with members of the enterprise as well as members 
of JIEDDO. With the testing completed the test agency posts the test report to the JTB 
web portal for all interested parties to view. The data within the test report is then used 
by the Knowledge Information Networking Group (KING) to generate products which 
can be easily interpreted by the end user and viewed on the TSWT. 

3. JTB RFI Process Simulation Results 

In 2010, the JTB responded to 55 REIs. Overall, the average time from REI 
initiation to a response available to the end user was 16 days. However, the response 
time varied greatly and was dependent upon on the method used to resolve the REI. The 
amount of time for a given activity was derived from the statistical research, and the 
distribution of those times was based upon a statistical analysis of the number of REI 
submitted in a calendar year and the amount of time taken to resolve the REI. Table 13 
displays the results of the statistical analysis conducted on the number of REIs submitted 
in 2010. The standard deviation for the open air and the modeling and simulation REIs is 
larger than the average time taken to resolve the REI due to the wide disparity in the 
number of days taken for REI resolution. 


Table 13. Results of JTB REI Statistical Analysis 


Type of resolution 

# RFI's 

Average time to 
resolution (in Days) 

Standard 

Deviation 

Paper/Lab Resolved 

18 

13.75 

12.2632118 

Open Air Resolved 

27 

13.74074074 

17.43910855 

Mod/Sim Resolved 

9 

32.88888889 

43.2274347 

Academic Analysis Resolved 

1 

4 

0 
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Figure 9 depicts the result of the JTB RFI Process simulation. It shows the 
average time spent at each of the activities. The information entered into each of the 
activities was based upon the data in Table 13. The OV-6C captured in the Provision tool 
can easily be adjusted to reflect changes to the RFI process or to any of the activities 
within the JTB RFI Process. These changes normally take, at most a few hours of effort. 
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Figure 9. RFI Process Simulation Result 
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D. DESCRIPTION OF THE SYSTEM VIEWPOINT 


The system viewpoint is used to illustrate how users access the JTB Portal. 




Figure 10. JTB Portal System Viewpoint-1 

Figure 10 depicts the users of the JTB Portal. The JTB Portal is structured as an 
Oracle database hosted at the Yuma Proving Grounds. Members of the theater support 
systems use the portal to gain information to assist in their development of procedures to 
be implemented in their Area of Operations. Members of the working groups have access 
to an area of the portal that can be utilized to post information. The testing agencies also 
have access to post the test reports and pull the information needed to support executed 
testing. The JTB Knowledge Information Networking Group (KING) designed the portal 
and also administers its use. However, it is also a user of the portal as it develops JTB 
Products after the test reports are posted. 

The JTB Portal contains links to other relevant websites and portals associated 
with the JTB Enterprise. For example the TSWT is a separate web portal. Therefore, 
separate accesses are required in order to utilize all of the tools available to the users. 
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V. CONCLUSIONS AND RECOMMENDATIONS 


The goal of this thesis is to analyze end-user interaction with the JTB, to support 
developing recommendations for improving this interaction. An architectural process 
capture method was used to identify key activities and support the analysis reported in 
this chapter, and is based on the literature review, which suggests three key elements to 
operating a successful process in support of war fighters. Those elements are 
organizational structure, collaboration, and the related information sharing that can best 
support the end user. The findings, conclusions, and recommendations of this chapter are 
based upon an analysis of the JTB Enterprise with respect to the three key elements. 
Since the interaction with the end user is most important, that activity analysis begins this 
discussion. 

A. IMPACT OF THE JTB ON THE END USER 

The interaction between the JTB and the end user is both direct and indirect. 
Direct interaction occurs through tools such as the Theater Support Web Tool (TSWT), 
which provides the mechanism for the end user to input a Request for Information (RFI). 
The TSWT also affords the end user the ability to track the status of the request to its 
resolution. The JTB also has direct interaction with the end user through pre-deployment 
training provided to the Electronic Warfare Officers (EWO). Training includes 
information about the purpose of the JTB and products developed. Indirect interaction 
occurs through the theater support elements (which could also be end users) as these 
elements use the information gathered from a resolved RFI to develop guidelines and 
procedures, which in turn are used by the end users. 

Until recently the theater support elements had a direct means of communication 
with the end users. Initially, EWOs from the Navy and the Air Force were first assigned 
to the theater support elements and then the theater support element units to whom the 
EWOs were assigned would embed the EWOs within deployed units. This gave the 
theater support elements a means of constant interaction with the end users. However, 
presently the Army has increased its cadre of EW officers, replacing the Navy and Air 
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Force EWOs, and these Army EWOs are now organic to deployed units. While this 
different dynamic has not completely severed the flow of information to and from the end 
users, it has hindered it. 

It was discovered through interviews with the end users that many of them were 
not familiar with the JTB but they were familiar with JIEDDO. Upon learning of the JTB 
each of the end users stated that the tools available on the JTB Portal would be useful in 
the field, implying they had not seen or used the JTB Portal or other associated web tools, 
such as the TSWT. Based on this research one recommendation is that the JTB conduct 
briefs periodically with EWOs in order to gain ideas to improve the support and/or 
products provided to the end users. The intention of these briefs would be to initiate a 
dialogue with the end users which would provide the JTB a means to improve all 
processes across the enterprise. Another recommendation is to invite EWOs to attend the 
weekly Video Teleconference (VTC). EWO attendance would greatly increase 
situational awareness, and this could be implemented by simply having battalion EWOs 
attend early in their rotation, or it could be requested that attendance to the VTC be part 
of the turnover process. 

JIEDDO uses social networking as a means to provide information to associated 
and interested personnel across its enterprise. This may also be a vehicle for the JTB to 
improve its visibility to the end user. Having a social networking site gives the JTB the 
ability to broadcast pertinent information to all personnel associated with the JTB. This 
social networking site could also be used to increase awareness about the JTB since it is 
not required to be associated with the JTB Enterprise in order to be a member of the JTB 
social networking site. 

B. ANALYSIS OF THE JTB ENTERPRISE 

The JTB Enterprise consists of relationships which have existed since the JTB 
was formed in 2006. As with any Enterprise, the JTB Enterprise contains organizations 
over which the JTB has no direct authority. In these cases the JTB has established 
working relationships, however there is no established guidance or written policy that 
specifies the nature of the relationship. The current relationships with the test sites are 
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established through contracts, however these contracts exist only between the JTB and 
the test site. Guidance that includes and describes the relationships between the 
organizations for the entire enterprise would increase situational awareness across the 
enterprise. 

1. Organizational Structure Analysis of the JTB Enterprise 

The structure of the JTB enterprise is aligned with three of the organizational 
structures described by Mintberg and discussed in Chapter II. The JTB enterprise 
combines the flexibility of the simple structure, the standardization of skills of the 
professional bureaucracy, and the ability to communicate across domains of the 
adhocracy. The JTB Enterprise is a flexible enterprise mainly due to the nature of the 
tasks which are being conducted by each of the activities of the enterprise. The 
environments the test sites are replicating are dynamic and the flexibility to adapt and 
change has proven to be a tremendous strength of the JTB Enterprise. It is not 
uncommon for a test to be planned and executed in a matter of days. This remarkable 
response time is achieved through existing working relationships, which have been 
forged over time. However, should any of the personnel exit the JTB enterprise then that 
line of communication could be severed resulting in a loss of flexibility. To maintain 
such flexibility, a set of guidelines or policy should be developed which promotes the 
growth of trust amongst people from the different organizations within the JTB 
enterprise. 

Standardization of skills, as in the professional bureaucracy, has been maximized 
by separating the type of testing conducted at each of the test sites. This division of labor 
has resulted in an increased level of specialization at the test sites, which has mitigated 
redundancy in testing, one of the five areas of authority given to the JTB by the DoD 
Directive. Reliance upon the operating core, that is, the test sites, and its ability to 
operate autonomously is another characteristic which indicates the JTB Enterprise 
operates as a professional bureaucracy. The independent environment of the professional 
bureaucracy calls for little coordination or formalization between each of the 
specializations of the operating core. It is the JTB that provides a means to coordinate 
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and collaborate through use of the JTB Portal, as seen in Figure 10, which depicts 
members of the operating core and the lines of communication to the JTB Portal. 

Communicating across domains, which refers to the way organizations interact in 
an adhocracy, may not be the ideal method for the JTB Enterprise. Communication is an 
essential attribute of organizations, however if the test sites were to begin coordinating 
without JTB oversight information could be lost and testing may become redundant. 

The JTB Enterprise falls within the Coordination quadrant of Eigure 1, as the 
enterprise is comprised of distinctive organizations that require access to shared 
information. The JTB Portal is the means the JTB has elected to provide shared 
information to the JTB Enterprise. 

2. Organizational Relationships within the JTB Enterprise 

Information gathered from the interviews provided the bulk of the information 
used to develop the OV-4, and were essential to understanding the existing relationships 
in the JTB Enterprise. However, the interviewees expressed a common concern 
regarding a lack of communication within the enterprise, which was attributed to the fact 
they did not know who or how to contact other members of the enterprise. This lack of 
communication could be mitigated by keeping an updated point of contact (POC) list. 
Developing and publishing a POC list could prove to be a daunting task, yet once 
compiled it could be invaluable, in terms of fostering an increase in communication 
throughout the enterprise. Due to the rate of turnover of personnel within the enterprise, 
it is recommended that the POC list be evaluated and updated on a quarterly basis. 
Consideration should also be given to posting this POC list on the JTB portal. 

Working groups are manned by subject matter experts in the field related to their 
respective working group, and are formed by the authority of the JTB Director. The JTB 
working groups provide a critical and useful service in the development of testing 
protocols. Currently there is no guidance governing the structure of the working groups. 
Using the discussion boards located on the JTB Portal to post information for each of the 
working groups would help ensure that the latest protocols are used in the testing process 
to provide the best support to the end user. 
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3. Final Analysis of the JTB Enterprise 

One glaring omission from the JTB Enterprise is the position of a Chief 
Information Officer (CIO) or a Chief Technology Officer (CTO). It is recommended that 
a CIO/CTO be appointed and given authority to institute policies and protocols which 
would govern the massive amounts of information produced by the test agencies. Each 
test report is written with the same structure, however most if not all of the data is held by 
the agency conducting the test. A CIO/CTO with authority could compile the data in a 
manner that would be useful to the Enterprise and assist in ensuring there is no 
redundancy in testing, as stated in the Directive. The JTB Enterprise can be used as an 
example of an organizational structure for many DoD as well as non-DoD organizations, 
since the level of complexity of the organization has been mitigated by using specialists 
to perform their tasks while the JTB, which is the strategic apex of the enterprise, 
provides the oversight required for the entire enterprise to perform its duties. 

C. THE JTB PROCESS ANALYSIS 

The JTB REI Process is efficient. Erom 2006 through 2010, over three hundred 
REIs have been processed. However, it is not the number of REIs that have been 
processed that is impressive, it is the flexibility and swiftness in which the REIs are 
tracked and resolved. The flexibility of the REI Process allows an REI to be prioritized 
and executed in a short amount of time, giving time-critical results to the end user. The 
process spans the entirety of the JTB Enterprise as each member of the Enterprise 
contributes to a portion of the process. These contributions range from personnel 
conducting tests to personnel generating REIs to budget analysts. 

1. JTB Process Collaboration 

Collaboration in the JTB REI Process is essential for the process to support the 
end user. The meaning of collaboration is to work together and the structure of the JTB 
REI Process encompasses the entire JTB Enterprise, thus capitalizing on the expertise of 
the personnel involved. Weekly VTCs support collaboration as all the stakeholders of the 
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JTB Enterprise as well as members of JIEDDO are able to provide information to each 
other. These VTCs help to provide situational awareness regarding the status of JTB REI 
Process. 

The JTB REI Process depicted in Eigures 5-8 includes only four decision points; 
however other decisions are made at various points of the process within some of the 
activities. These decisions are made by the subject matter experts and are vetted through 
the rest of the JTB REI Process stakeholders at the weekly SVTC. The collaborative 
environment of the JTB REI Process has been evolving into this current state which is 
effective, and as it continues to evolve it will increase its product and support thus giving 
the end users a competitive advantage over their adversaries. 

2. JTB Process Recommendations 

The process may be efficient; however, there are a few areas where it can be 
improved. Currently, there is no policy governing the process; the only information 
uncovered regarding the REI Process was a TSWT user manual which is located on the 
SIPRnet. The user manual provides instruction on generating an REI. It also provides a 
description of the process, yet the authority to execute the process is nonexistent. While 
it may seem trivial to have a policy written which would restate what is currently 
happening, a written policy would be beneficial to the end users as it would inform all 
participants of the process that occurs in each of the activities. This policy can then lead 
to the JTB REI Process certification. Certifying the process could give the JTB the 
flexibility to interchange personnel without disrupting the JTB REI Process. 

Another recommendation is to institute a tracking mechanism for the REI Process, 
which can be implemented by updating the REI submission form. Currently the 
submission form does not offer a means to input any personal information, such as an e- 
mail address. The ability to provide an e-mail address to be attached to the REI as it 
traverses the process gives everyone associated with that REI an efficient way to reach 
out to the person who submitted the REI to gain further information (if required). A 
tracking mechanism could also provide a way for the person who submitted the REI to 
receive automatic status updates at different REI Milestones, such as when it is resolved. 
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It would also prove useful if the end user, more specifically the EWOs, could 
have a static email address assigned by the JTB. A static email address that would be 
turned over between personnel, would improve the lines of communication. This email 
address could be used by the JTB to reach out to the end user should questions arise 
about an RFI. 

D. THE JTB PORTAL 

The JTB Portal was analyzed while conducting the research needed for the 
development of the OV-6. The portal has useful links to the organizations associated 
with the JTB Enterprise. A username and password are required to access the Portal, thus 
controlling access; however each of the websites needed for the RFI Process requires 
different usernames and passwords. A single sign-on portal would allow one to generate 
an RFI within one session. The portal also has discussion boards for each of the working 
groups to use for collaboration; however most are not used nor had been used in over a 
year. A CIO/CTO, as recommended earlier in this chapter, given proper authority could 
require the use of the message boards and the portal. The use of the JTB Portal would 
provide a central point for all information generated by the JTB Enterprise to flow. The 
Portal has the potential to become a relevant source of information to the end user, yet 
without policy or a public relations campaign it will continue to be a useful tool that goes 
unused. 

E. AREAS FOR FUTURE RESEARCH 

The models that have been developed for this research were intended to uncover 
and make explicit the interactions of the JTB with the end users, however the models can 
offer much more than a display of the information flow used for the JTB RFI Process. 
The software tool used to develop the models includes algorithms which can analyze 
other variables, most notably cost. The JTB RFI Process can be manipulated to conduct 
“what if’ analyses, such as updating each of the activities to reflect its monetary value. 
Analysis of this nature could be used in determining the cost of the current process. Once 
cost is established the model can then be used to determine ways to resolve RFIs in a way 
that is more fiscally efficient. Cost is not the only variable that can be manipulated; the 
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efficiency of the model can also be analyzed, in order to develop alternative methods 
which would increase the level of support to the end user. 

F. FINAL ANALYSIS 

The JTB as an Enterprise and an organization is efficient and adheres to the 
guidance set forth by the DoD Directive. Documenting the JTB Enterprise, its people, 
processes, and products, and instituting guidance to govern the enterprise will be essential 
to the JTB Enterprise as it continues to counter the dynamic threat by U.S. adversaries. 
This will become increasingly important as the United States withdraws forces from the 
Middle East, and the nature of counter lED work evolves in the future. 
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